home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 4⁄27⁄90 / 1214-PostRes() Revisited-Apr90 < prev    next >
Encoding:
Text File  |  1990-04-27  |  4.3 KB  |  100 lines  |  [TEXT/GEOL]

  1. Item forwarded  by  A33          to A34
  2.  
  3. Item    2997865                         27-April-90        05:37PDT
  4.  
  5. From:   POWERUP.ENG                     Power Up Software,PRT
  6.  
  7. To:     MACAPP.TECH$                    MacApp Technical
  8.         S.FRIEDRICH                     Friedrich, Steve
  9.         KSI                             Knowledge Source, V Johnson,PRT
  10.  
  11. Sub:    PostRes() Revisited
  12.  
  13. Attn:   MacApp.Tech$
  14. Attn: Steve Friedrich
  15. Attn:   KSI
  16. SentBy: James Plamondon
  17. Date   4/26/90
  18. Subject    PostRes() Revisited
  19. From   James Plamondon
  20. To   KSI
  21. CC Steve Friedrich,   MacApp.Tech$
  22.  
  23. Subject:   PostRes() Revisited
  24. Dear Mike,
  25.  
  26. I like your proposed mechanism of initializing owned objects via calls of the
  27. form SELF.SetOwnedThing(SELF.MakeThing) in TOwner.IRes(); however, as you
  28. pointed out, it has its own problems.
  29.  
  30. Consider a class TFoo, which contains an owned object of class TThing.  The
  31. owned object is refered to via the field fThing.  The owned object is created
  32. via a call to TFoo.MakeThing.  The question is — when should MakeThing be
  33. called?
  34.  
  35. If the line "fThing := MakeThing;" appears in TFoo.IRes(), then it must be
  36. true that TFoo contains all necessary information for the creation and
  37. initialization of the TThing being created.  (This would still be a limitation
  38. even if MakeThing() could be overriden to take additional arguments, as can be
  39. done in C++, because the arguments would have to be available to TFoo.IRes().)
  40.  
  41.  
  42. However, as you pointed out, the inheritance tree of TThing may parallel that
  43. of TFoo — that is, subclasses of TThing may need information provided by
  44. subclasses of TFoo.  For example, TBar (a subclass of TFoo) may own a
  45. TBarThing which requires knowledge embodied in TBar.  This information is not
  46. available to TFoo.IRes(), because it hasn't been read in yet when TFoo.IRes()
  47. is called — it is read in by TBar.IRes().
  48.  
  49. If the information is not available when TFoo.IRes() is called, then it isn't
  50. available when TFoo.IRes() calls MakePeriod(), either, even though
  51. MakePeriod() is polymorphic, so that TBar.MakePeriod() is called.  Therefore,
  52. MakePeriod() has to be called from TBar.IRes(), not from TFoo.IRes().
  53.  
  54. But — what if TBar has a subclass (TFubar), which owns a TFubarThing, which
  55. requires information read in by TFubar.IRes()?  When TFoo.IRes() calls
  56. MakeThing(), TFubar's MakeThing() will be called, but the information it needs
  57. will not yet be available.  And so the problem cascades down the inheritance
  58. tree, ad infinitum.
  59.  
  60. This problem could be resolved by augmenting IRes() with the oft-requested
  61. PostRes() routine.  IRes() would work exactly as it does now — reading in the
  62. view resource, and doing whatever initialization were possible.  The
  63. initializations done in IRes() are limited not only by the subclassing problem
  64. described below, but also by the fact that SELF's subviews don't exist when
  65. IRes() is called on SELF.
  66.  
  67. Then, after the entire view hierarchy was initialized via IRes(), a post-order
  68. traversal would be made through the view hierarchy, calling PostRes() on each
  69. encountered view.  PostRes() would then call MakeThing(), and all our problems
  70. would be over.
  71.  
  72. A post-order traversal would assure that SELF's subviews would already be
  73. initialized with PostRes() before PostRes() was called on SELF.  This
  74. complements the in-order traversal used in IRes().
  75.  
  76. If we really wanted to be general, we could also add a BreadthFirstRes() pass,
  77. which would assure that all views that were ancestors (or siblings of
  78. ancestors) of SELF were initialized with BreadthFirstRes() before
  79. BreadthFirstRes() was called on SELF.  Then comes the question, which do you
  80. do first — the breadth-first pass or the post-order pass?  You've got me
  81. there.  If it mattered, it would imply that having these two distinct passes
  82. was the wrong solution.
  83.  
  84. Maybe now that the MacApp folks at Apple are actually done with MacApp 2.0
  85. final (hurray!  great job!), and they're laying around the pool wondering what
  86. to do next, they could tackle the PostRes() issue — one of the few MacApp
  87. issues one which Curtis Faith and I have found ourselves in agreement [:-)].
  88. That alone is strong evidence that this really is a useful feature.
  89.  
  90. Of course, I could be way off base, and the proposed PostRes() routine might
  91. be just a demonstration of my ignorance.  If so, I'd love to be educated by
  92. somebody as to the Truth about PostRez().
  93.  
  94. Looking forward to PostRes(), I remain
  95.  
  96. Yours,
  97.  
  98. James Plamondon
  99.  
  100.